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(54) A method for controling a Middlebox 



(57) In order to carry out actions such as setting up 
a call from an entity in the address realm of one middle- 
box to an entity in the address realm of another middle- 
box, then a middlebox control node such as a call server 
is used. Previously, the middlebox control node has 
needed to have pre-configured information about all the 
middleboxes and which address realms they are asso- 
ciated with. The present invention provides one or more 



middlebox-identity-providing nodes which are separate 
from the middlebox control node, and which are more 
directly connected to the end users of the service than 
the middlebox control node. This provides greater flex- 
ibility in network design and removes the need for mid- 
dlebox information to be pre-configured at the middle- 
box control node. Instead, this information is sent to the 
middlebox control node, as part of signalling messages, 
from middlebox-identity-providing nodes. 
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, Description 

FIELD OF THE INVENTION 

[0001] The present invention relates to a method of s 
controlling one of a plurality of middleboxes in a com- 
munications network. 

BACKGROUND TO THE INVENTION 

10 

[0002] A middlebox is a node in a communications 
network that is connected between two address realms 
in that communications network. An address realm is a 
region of the communications network in which each of 
the entities within that region have an address or iden- '5 
tifier which is unique within that region and which is al- 
located according to a particular method. The term "ad- 
dress domain" is also used to refer to an address realm. 
[0003] An example of a middlebox is a network ad- 
dress translator (NAT) which converts the unique ad- 20 
dresses of one address realm into those of another ad- 
dress domain. Another example is a firewall which pro- 
vides a secure connection between the two address 
realms and a further example is a quality of service reg- 
ulation device which operates between the two address 25 
realms. Thus a middlebox is typically associated with a 
single address realm which it connects to one or more 
other address realms. 

[0004] In order to carry out actions such as setting up 
a call from an entity in the address realm of one middle- 30 
box to an entity in the address realm of another middle- 
box, then a middlebox control node such as a call server 
is used. Previously, the middlebox control node has 
needed to have information about all the middleboxes 
and which address realms they are associated with. The 35 
middlebox control node is then able to use this informa- 
tion to control the particular middleboxes. 
[0005] The information is typically p re-configured in 
the middlebox control node. However this method is dis- 
advantageous. For example, if the information is pre- 40 
configured it is difficult to make changes to the middle- 
box locations or to add middleboxes without the need 
for the information at the middlebox control node to be 
updated. Also, if the middlebox information is statically 
configured it is not possible to cope with situations 45 
where different middleboxes are used depending on 
middlebox status, loading or call destination for exam- 
ple. The method is inflexible and unable to cope satis- 
factorily with situations in which the same user is con- 
nected to different middleboxes at different times (e.g. so 
a mobile user). 

[0006] Another method that has been considered in- 
volves using the source addresses of call signalling 
packets received at the middlebox control node from the 
middleboxes. These source addresses provide details 55 
of the middlebox addresses. However, this method does 
not work in situations where there are devices in the path 
between the middlebox and the middlebox control node. 
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In addition, this method assumes that the same middle- 
box should be used for call signalling messages as for 
user messages (media). Also, this method requires ad- 
ditional datafill at the middlebox control node in order to 
map the middlebox source address to a middlebox con- 
trol node address. 

[0007] An object of the present invention is to provide 
a method of controlling a middlebox which overcomes 
or at least mitigates one or more of the problems noted 
above. 

[0008] Further benefits and advantages of the inven- 
tion will become apparent from a consideration of the 
following detailed description given with reference to the 
accompanying drawings, which specify and show pre- 
ferred embodiments of the invention. 

SUMMARY OF THE INVENTION 

[0009] According to an aspect of the present invention 
there is provided a method of controlling one of a plu- 
rality of middleboxes in a communications network, 
each of the middleboxes being connected to a plurality 
of entities in an address realm of the communications 
network, said method comprising the steps of:- 

• receiving a control message at a middlebox-identi- 
ty-providing node in the communications network, 
said control message comprising information about 
one of the entities in the communications network; 

• using the middlebox identity providing node to de- 
termine the identity of a first middlebox connected 
to said one entity; 

• sending said identity to a middlebox control node in 
the communications network in order to control said 
first middlebox; 

• and wherein the middlebox-identity-providing node 
is separate from the middlebox control node and is 
more directly connected to said one of the entities 
than the middlebox control node. 

[001 0] For example, the middleboxes may be network 
address translators and the control message may be a 
call set-up request message containing information 
about a user terminal which originated the call set-up 
request. The middlebox control node may be a call serv- 
er which provides a service to the entities in the address 
realm which are preferably user terminals in an enter- 
prise network. By sending the identity information to the 
middlebox control node in this way, the advantage is 
achieved that the middlebox control node does not need 
to have pre-configured information about middlebox 
identities. The middlebox control node does not need to 
maintain a list of all the client (e.g. user terminal) to mid- 
dlebox relations. Also, greater flexibility in network de- 
sign with regard to the number and location of middle 
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boxes is possible. 

[0011] Preferably said identity is added to a control 
message which is sent to the middlebox control node. 
This provides a simple and effective means in which the 
identity information can be sent to the middlebox control 
node. Other information can also be added in addition 
to the identity information. For example, some middle- 
boxes can have additional properties such as being split 
into virtual middleboxes. Knowledge of these additional 
properties can also be added to the control message. 
[0012] In a preferred example, the control message is 
a session description protocol (SDP) message and the 
middlebox identity is added to that message using a pre- 
specified SDP attribute. SDP is defined in the Internet 
Engineering Task Force (IETF) Request for Comments 
(RFC) number 2327 of April 1998. However, this is not 
essential. Other methods can be used, such as adding 
the identity information to the control message in an in- 
ternet protocol (IP) header. 

[0013] In one embodiment the control message is a 
call set-up message and said method is arranged to 
control said first middlebox in order to set-up a call from 
said one entity to another entity connected to a second 
middlebox in the communications network. This is de- 
scribed in detail below with reference to Figure 2 for ex- 
ample where the two entities are user terminals A and 
B. Preferably the second middlebox is connected to a 
plurality of entities in a second address realm different 
from the first address realm of the entities connected to 
the first middlebox. For example, user terminal B is in 
address realm D2 which is different from address realm 
D1 of user terminal A, The middlebox control node is 
then within a third address realm different from the first 
and second address realms. For example, in Figure 2, 
the middlebox control node is a call server in address 
realm D3. That call server can for example, provide a 
service to entities in address realms D1 and D2 which 
could be enterprise networks. 

[0014] According to another aspect of the present in- 
vention there is provided a communications network 
comprising: 

• a plurality of middleboxes, each connected to a plu- 
rality of entities in an address realm of the commu- 
nications network; 

• a middlebox-identity-providing node arranged to re- 
ceive a control message comprising information 
about one of the entities and to determine the iden- 
tity of a first middlebox connected to said one entity; 

• a middlebox control node arranged to receive the 
determined identity of the first middlebox in order to 
control said first middlebox; said middlebox-identi- 
ty-providing node being separate from the middle- 
box control node and being more directly connected 
to said one of the entities than the middlebox control 
node. 



[0015] According to another aspect of the invention 
there is provided a signal comprising a session descrip- 
tion protocol message comprising an attribute contain- 
ing information about the identity of a middlebox. This 
5 provides a simple and effective means to send such in- 
formation to a middlebox control node. 
[0016] According to another aspect of the present in- 
vention there is provided a middlebox control node ar- 
ranged to control a plurality of middleboxes in a com- 
10 munications network, said middlebox control node com- 
prising: 

• an input arranged to receive a control message 
comprising information about the identity of one of 

15 the middleboxes; 

• a processor arranged to issue messages to the 
identified middlebox in order to control it; such that 
in use the middlebox control node is able to control 

20 the identified middlebox without the need to main- 
tain its own store of information about the identities 
of the middleboxes and without the need to maintain 
its own discovery mechanism to discover the iden- 
tities of the middleboxes. 

25 

[0017] A computer program for controlling such a mid- 
dlebox control node is also provided using any suitable 
programming language as is known in the art. For ex- 
ample, the middlebox control node may be any suitable 
30 type of call server such as a communications server as 
available from Nortel Networks. Preferably the middle- 
box control node uses the MIDCOM protocol (see be- 
low) for controlling middleboxes. 
[001 8] According to another aspect of the present in- 
35 vention there is provided a middlebox-identity-providing 
node for use in a communications network comprising 
a plurality of middleboxes, said middlebox identity pro- 
viding node comprising: 

40 • an input arranged to receive a control message 
comprising information about one of a plurality of 
entities in the communications network; 

• a processor arranged to determine the identity of a 
45 first middlebox connected to said one entity; 

• an output arranged to send said identity to a mid- 
dlebox control node in the communications net- 
work; and wherein said middlebox-identity-provid- 

50 ing node is arranged to be more directly connected 
to said one of the entities than the middlebox control 
node. 

[0019] If we consider the middlebox control node as 
55 a call server which provides a service to clients such as 
user terminals (e.g. terminals A and B in Figure 2) then 
the middlebox-identity-providing node can be any node 
on the path between the client and server through which 
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# the control messages pass. For example, a middlebox 
itself may be used as the middlebox-identity-providing 
node. This embodiment is particularly advantageous in 
the case that the middlebox is the only node to know 
which middlebox the client is assigned to. For example, 
this may occur when the client is dynamically assigned 
to a particular middlebox. 

[0020] A computer program for controlling such a mid- 
dlebox-identity-providing node is also provided using 
any suitable computer programming language as is 
known in the art. 

[0021 ] A particular advantage of the present invention 
is that it allows a Business services channel manager 
(as commercially available from Nortel Networks) to be 
integrated into a communication server 2000 network 
(as commercially available from Nortel Networks) where 
that network includes MIDCOM-controlled NAT middle- 
boxes. 

[0022] The preferred features may be combined as 
appropriate, as would be apparent to a skilled person, 
and may be combined with any of the aspects of the 
invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0023] I n order to show how the invention may be car- 
ried into effect, embodiments of the invention are now 
described below by way of example only and with refer- 
ence to the accompanying figures in which: 

Figure 1 is a schematic diagram of a communica- 
tions network with middleboxes according to the pri- 
or art; 

Figure 2 is a schematic diagram of a communica- 
tions network with gateways that provide middle- 
box-identity-providing functionality; 

Figure 3 is a flow diagram of a method of setting up 
a call using the communications network of Figure 

2; 

Figure 4 is a schematic diagram of a communica- 
tions network with user terminals that provide mid- 
dlebox-identity-providing functionality; 

Figure 5 is a flow diagram of a method of setting up 
a call using the communications network of Figure 
4; 

Figure 6 is a schematic diagram of a communica- 
tions network with middleboxes that provide middle- 
box-identity-providing functionality; 

Figure 7 is a flow diagram of a method of setting up 
a call using the communications network of Figure 
6; 



Figure 8 is a message sequence chart showing a 
discovery algorithm according to the prior art. 

DETAILED DESCRIPTION OF INVENTION 

5 

[0024] Embodiments of the present invention are de- 
scribed below by way of example only. These examples 
represent the best ways of putting the invention into 
practice that are currently known to the Applicant al- 
10 though they are not the only ways in which this could be 
achieved. 

[0025] Figure 1 is a schematic diagram of a commu- 
nications network according to the prior art comprising 
two middleboxes 10, 11 and three address realms D1, 

15 D2, D3. Middlebox 1 is connected between address 
realm D1 and address realm D3 whilst middlebox 2 is 
connected between address realms D2 and D3. Each 
address realm contains a plurality of network nodes or 
entities connected together and this is represented in 

20 Figure 1 using "cloud" shapes. Some of those network 
nodes are user terminals such as user terminal A, 1 4 in 
address realm D1 and user terminal B, 16 in address 
realm D2. Also, in address realm D3, one of the network 
nodes is a call server or proxy 1 8. 

25 [0026] The communications network of Figure 1 may 
be a voice over internet protocol (VO I P) network, a voice 
over asynchronous transfer mode (ATM) communica- 
tions network or other suitable type of network. When a 
call is set up between user terminal A and user terminal 

30 B, call signalling occurs between those two terminals 1 4, 
1 6. This also applies when the call involves other media 
such as video or data instead of or in addition to voice. 
This call signalling follows the path indicated by the ar- 
row labelled S in Figure 1 . As a result of this call signal- 

35 ling, in an internet protocol (IP) network, a media or 
bearer path is set up in the reverse direction from user 
terminal B to user terminal A as indicated by arrows B 
in Figure 1 . This process is repeated in the other direc- 
tion such that a media path from the originating party (in 

40 this case userterminal A) to the destination party (in this 
case userterminal B) is also set up. In an ATM network, 
after the initial call signalling, further signalling occurs 
as a result of which a bidirectional media path is set up 
between the parties. 

45 [0027] As shown in Figure 1 , the media path travels 
via middleboxes 1 and 2 and this is required because 
those middleboxes are arranged to perform one or more 
tasks associated with the connections between the dif- 
ferent address realms. For example, the middleboxes 

so could be firewalls, network address translators (NATs) 
or quality of service control devices. The call server 18 
is used to control the middleboxes as indicated by ar- 
rows M in Figure 1 . For example consider the situation 
in which a call is to be set-up between user terminal A 

55 and user terminal B, and the middleboxes 1 and 2 are 
NATs. In this case, assume that the address realms D1 
and D2 are private whilst address realm D3 is public. 
For example address realm D1 may be the communica- 
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. tions network of a particular enterprise and that of D2 
the network of another enterprise. The term "public" is 
used here in a special sense to indicate that entities 
within D1 and D2 are able to route to the entities in D3 
because the addresses of D3 entities are available to 
D1 and D2 entities "publicly". However, address realms 
D1 and D2 are not public with respect to address realm 
D3. That is, entities in realm D3 cannot simply route to 
entities in D1 or D2 because the addresses of D1 and 
D2 entities are not directly available to D3 entities. In 
this way there is an asymmetry in the connections be- 
tween address realms D3 and D1 or D3 and D2. A serv- 
ice provider may offer a voice or multimedia service to 
the enterprises of D1 and D2 and do this using the call 
server 18 connected to address realm D3. The voice or 
multimedia service is referred to as being hosted outside 
the enterprise networks to which the service is offered. 
[0028] In order for a media path to be set up, the NATs 
need to set up address bindings and the call server is 
used to request those bindings from the NATs as indi- 
cated in Figure 2. 

[0029] These address bindings are required in order 
to enable the media path to be routed from middlebox 
2 to a part of middlebox 1 which is in D3 and from that 
D3 public location to D1 which is a private address 
realm. In other cases, in which the middleboxes are fire- 
walls or quality of service devices, it is also necessary 
for the middleboxes to be controlled in order to complete 
the required task such as setting up a call or allowing 
non-call related data paths to be established, for exam- 
ple, for auditing. This control has previously been 
achieved by issuing control or signalling messages from 
the call server 18, or other middlebox control node, to 
the middleboxes 10, 11. In order to do this, the call serv- 
er 18 or other middlebox control node needs to know 
about the existence and location of each middlebox and 
which address realms those middleboxes are connect- 
ed to. Previously, this middlebox information has been 
pre-configured in the call server 1 8 or middlebox control 
node and this is problematic for the reasons explained 
above. 

[0030] Another problem concerns the location of the 
middlebox control node in relation to the user terminals 
A, B. If the communications network is considered as 
comprising layers of address realms, the middlebox 
control node has previously been located in a higher lay- 
er than the user terminals of the subscribers to the serv- 
ice in the enterprise networks. The present invention lies 
in recognising this problem and realising that inflexibility 
in network design results. For example, the ability to 
change based on loading or availability of middleboxes 
is more restricted as a result. 

[0031] The present invention addresses these prob- 
lems by providing one or more middlebox-identity-pro- 
viding nodes which are separate from the middlebox 
control node, and which are more directly connected to 
the end users of the service than the middlebox control 
node. Effectively, some of the tasks of the middlebox 



control node are devolved to other network nodes which 
are located closer to the end users or clients. This pro- 
vides greater flexibility in network design and removes 
the need for middlebox information to be pre-configured 
5 at the middlebox control node. Instead, this information 
is sent to the middlebox control node, as part of signal- 
ling messages, from other network nodes which are re- 
ferred to herein as middlebox-identity-providing nodes. 
[0032] These middlebox-identity-providing nodes 
10 may be located at any suitable position in the commu- 
nications network and for example may be incorporated 
in gateway nodes in the same address realm as the call 
server, in the middlebox themselves, or in the user ter- 
minals themselves. These examples are discussed in 
15 detail below with respect to Figures 2 to 7. 

[0033] The middlebox-identity-providing nodes either 
have pre-configured middlebox identity information or 
use a network analysis method to determine the infor- 
mation automatically. This type of automatic method will 
be referred to herein as "discovery". Any suitable dis- 
covery method can be used as known in the art. For ex- 
ample, Figure 8 is a message sequence chart for a pre- 
ferred discovery method. Figure 8 is discussed in more 
detail below. 

[0034] The middlebox-identity-providing node sends 
the middlebox identity information to the middlebox con- 
trol node. Any suitable identifier can be used forthe mid- 
dlebox identity. For example, a fully qualified domain 
name (FQDN), an internet protocol (IP) address or any 
other suitable unique identifier. In the case that the mid- 
dlebox is a NAT the identity may be the IP address of 
the public side of the NAT. More detail about how the 
middlebox identity information is sent is given below in 
the section headed "sending middlebox identity informa- 
tion". In the case that an FQDN is used, that FQDN may 
be extended to include more information about the mid- 
dlebox. This additional information may be carried in a 
separate field of the control message if the FQDN meth- 
od is not used. For example, in some embodiments one 
particular "middlebox" node effectively provides two or 
more middleboxes. That is, the node is arranged to act 
as two or more independent middleboxes. In such a 
case additional information is required to specify not on- 
ly the identity of the middlebox node but also the identity 
of the particular middlebox functionality within that node. 
This additional information would then also be added to 
the control message. 

[0035] Figure 2 is a schematic diagram of a commu- 
nications network incorporating middlebox-identity-pro- 
viding nodes according to an embodiment of the present 
invention. Figure 2 is similar to Figure 1 and identical 
reference numbers are used to refer to identical items 
in those figures. In the example shown in Figure 2, ad- 
dress realm D3 contains two gateway nodes, 20, 21 
which are connected to the call server 18 (possibly in- 
directly). Those gateway nodes 20, 21 act as the mid- 
dlebox-identity-providing nodes. That is they have infor- 
mation about middleboxes 1 and 2 either through pro- 
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visioning (pre-configured information), by discovery or 
by any other suitable means. 

[0036] Consider the situation in which middleboxes 1 
and 2 are NATs and it is required to set up a call from 
user terminal A 14 to user terminal B 16. A method is 
followed as indicated in Figure 3. User terminal A 14 
sends a call set-up message to gateway A 20. For ex- 
ample, this is achieved because user terminal A knows 
the address of gateway A in advance and is arranged 
to forward all call set-up messages to gateway A. The 
call set-up message contains details of the entity which 
originated it, i.e. user terminal A in this example. 
[0037] Gateway A then finds the identity of the mid- 
dlebox associated with the originator of the call set-up 
request (i.e. user terminal A and middlebox 1). For ex- 
ample, Gateway A achieves this by checking its pre- 
configured middlebox information or by using a discov- 
ery method (see box 30 of Figure 3). 
[0038] Gateway A next forwards the call set-up mes- 
sage to the call server, or middlebox control node, hav- 
ing first added the identity of middlebox 1 to that control 
message (see box 31 of Figure 3). The call server 18 
receives the call set-up message and obtains the mid- 
dlebox identity. Using this identity information the call 
server is able to send control messages to middlebox 1 , 
for example, to set up an appropriate binding for the call. 
In the example shown in Figure 2 a binding is obtained 
for middlebox 1 and passed on from the call server to 
gateway B (see box 32 of Figure 3). Gateway B then 
forwards the binding information for middlebox 1 on to 
user terminal B. Media can then be sent from user ter- 
minal B to user terminal A. The same process operates 
in the other direction in order to set-up a media path from 
user terminal A to user terminal B. User terminal B then 
sends its private address to gateway B. Gateway B de- 
termines the identity of the middlebox associated with 
user terminal B (i.e. of middlebox 2) and sends that iden- 
tity to the call server. The call server then instructs mid- 
dlebox 2 to create a binding to user terminal B, and user 
terminal A is informed of the results. Media can then be 
sent from user terminal A to user terminal B. 
[0039] In another embodiment, the middlebox-identi- 
ty-providing nodes are the user terminals themselves. 
This is illustrated in Figures 4 and 5. Figure 4 is similar 
to Figures 1 and 2 and identical reference numbers are 
used for the same items. However, the user terminals 
14, 16 in Figure 4 are different from those of Figures 1 
and 2 because they have middlebox-identity-providing 
functionality. 

[0040] Consider the case that a call is to be set-up 
from user terminal A to user terminal B and the middle- 
boxes are NATs. User terminal A finds the identity of its 
associated middlebox, for example, by using pre-spec- 
ified information or by using a discovery algorithm (see 
box 40 of Figure 5). User terminal A then sends a call 
set-up message to the call server 1 8 containing the iden- 
tity of middlebox 1 . Using this identity information the 
call server is able to send control messages to middle- 



box 1 to create a binding and the results of this binding 
are sent back to the call server. The call server then for- 
wards this to user terminal B. Similarly, middlebox 2's 
address is obtained from user terminal B, and used by 
5 the call serverto instruct middlebox 2 to create a suitable 
binding. The results of that binding are then sent to user 
terminal A. 

[0041] In another embodiment the middlebox-identi- 
ty-providing nodes are the middleboxes themselves. 
w This is illustrated in Figures 6 and 7. Figure 6 is similar 
to Figure 4 and identical reference numbers are used 
for the same items. However in Figure 6, the middlebox- 
es 1 and 2 have the identity-providing functionality rath- 
er than the user terminals. 

[0042] Consider again the situation in which it is re- 
quired to set-up a call between user terminal A and user 
terminal B and where the middleboxes comprise NATs. 
In this case user terminal A sends its call set-up request 
to middlebox 1 on route to the call server 18. Middlebox 
1 adds its own identity to the call set-up message and 
forwards it to the call server (see boxes 60 and 61 of 
Figure 7). The call server then instructs the middlebox 
1 to set up a binding as in the examples of Figures 3 
and 5. The results of the binding are sent to the call serv- 
er which passes them on to user terminal B. Similarly, 
the call server obtains middlebox 2's address from mid- 
dlebox 2 and instructs it to set up a binding. The results 
of that binding are sent to the call server and from there 
to user terminal A. 

[0043] In these examples the situation of call set-up 
is considered. However the invention is equally applica- 
ble to other tasks in which middlebox control is required 
such as allowing non-call related data paths as men- 
tioned above. Other examples involve bringing up me- 
dia streams during a call (e.g. for video, file transfer, 
whiteboard, application sharing) where those media 
streams may potentially take a different media path from 
the main call. Also, the examples discussed above all 
involve using NATs. However the middleboxes may in- 
stead be firewalls, quality of service devices or any other 
suitable type of middlebox. 

Sending the middlebox identity 

[0044] The middlebox identity is preferably sent by in- 
corporating it into a call signalling message such as a 
call set-up request. For example, it may be added as a 
new parameter in the call signalling message or carried 
as an optional IP header. In a preferred embodiment the 
identity information is added as a new parameter in a 
session description protocol (SDP) message as follows: 

v= 0 

c= IN IP4 47.86.54.32 
m = audio 345 RTP/AVP 0 
a = mbid: FQDN com.Nortel.middleboxl .logicalb 

[0045] Where mbid is a new attribute to be defined as: 



20 



25 



30 



35 



40 



45 



50 



6 



11 



EP1 315 359 A2 



12 



Middlebox-ID-attribute = "a=mbid: a id-type mbid- 
tag 

id-type = [FQDN I IP4 I token] 
mbid-tag = token 

[0046] The v=, c= and m= lines are standard SDR The 
value of v defines the protocol version being used whilst 
the value of c is an IP version 4 address for one end of 
the connection. The value of m in this case specifies that 
the media will be audio, sent or received as RTP in pay- 
load format o (G711U) to/from port 345. In SDP, an a= 
line is used to give attribute information. There may be 
several a= lines for different attributes or for the same 
attribute. The attribute is given by the string following 
the a=, in this case mbid. 

[0047] The definition given here is in Backus-Naur 
Form (BNF) as described in RFC-2234, and allows a 
suitable SDP parser to verify the a=mbid line as valid 
SDP. 

[0048] The mbid attribute is defined as having two 
fields: the id-type and the mbid tag. The id-type is de- 
fined as being either the string FQDN, the word IP4, or 
some other string (token), and the mbid-tag is defined 
as a string (token). 

[0049] Use of such a new SDP attribute or parameter 
needs to be registered with the IANA (Internet Assigned 
Numbers Authority). Also, the middlebox-identity-pro- 
viding node is arranged to be able to add such informa- 
tion to the control message. In the case that a new SDP 
attribute is used, then the middlebox-identity-providing 
node is required to be "application aware", that is, to 
have capability to make changes to the body of the con- 
trol messages. Another option is to use an IP header as 
mentioned above. The advantage of this is that the mid- 
dlebox-identity-providing node does not need to be "ap- 
plication aware"; rather it simply adds.the IP header. The 
content of the body of the control message could even 
be encrypted in this case. 

[0050] The middlebox identity can be added to the 
control signalling or messages at any node that the sig- 
nalling passes from the user terminal or client upwards 
to the call server. For example, we have discussed using 
the client itself, the middlebox, and a gateway with re- 
spect to Figures 2, 4 and 6. 

[0051] In some embodiments more than one middle- 
box is involved in the communications path. For exam- 
ple, the call may pass through a firewall and then a NAT. 
In that case, the middlebox identity information for each 
middlebox involved is added in sequence to the control 
message. For example, in the SDP example above, sev- 
eral a=mbid lines could be added to the message. Thus, 
either one middlebox-identity-providing node adds sev- 
eral middlebox identifiers in sequence, or several mid- 
dlebox-identity-providing nodes each add a middlebox 
identifier. Thus the ability to chain middlebox identity in- 
formation is achieved. 



Discovery Algorithm 

[0052] As mentioned above, the middlebox-identity- 
providing node can use any suitable discovery algorithm 
5 to automatically obtain information about the identity of 
middleboxes. This provides the advantage that it is not 
necessary to pre-configure the middlebox-identity-pro- 
viding node with middlebox-identity information. 
[0053] A preferred example of a discovery algorithm 

10 according to the prior art is now discussed with refer- 
ence to Figure 8 which is a message sequence chart. 
The vertical lines in Figure 8 represent nodes in the com- 
munications network. Line 70 represents a user termi- 
nal, line 71 represents a port of a middlebox connected 

13 to a first address realm of the user terminal, line 72 rep- 
resents a port of the middlebox connected to a different 
second address realm and line 73 represents an echo 
server in the second address realm. Line 74 represents 
a middlebox-identity-providing node in the second ad- 

20 dress realm. In this example line 74 represents a Busi- 
ness Services Channel Manager (BSCM) as commer- 
cially available from Nortel Networks. Line 75 repre- 
sents a middlebox control node and call server which in 
this example is a Communications Server as available 

25 commercially from Nortel Networks. 

[0054] The arrows in Figure 8 represent control signal 
messages between nodes in the communications net- 
work, with the relative positions of the arrows vertically 
on the page representing the sequence of those mes- 

30 sages in time. 

[0055] Consider the situation in which the terminal 70 
requires to set up a call. The terminal sends a registra- 
tion message 80 to the middlebox 71 , 72 which forwards 
that message to the BSCM 74. The BSCM then sends 

35 a resolve port mapping message 81 through the middle- 
box to the terminal. This message contains the address 
and port of the echo server (Z:z) (whereto send the port 
mapping discovery message to). The terminal sends a 
Port Mapping Discovery message containing the termi- 

40 nals address and port (A:b) through the middlebox to 
the echo server. In passing through the middlebox, the 
address and port of the terminal is replaced with the ad- 
dress and port of the NAT bind (R:r) in the source ad- 
dress. The echo server replies to the message with a 

45 PMDAck containing this address and port (R:r). On re- 
ceiving this, the Terminal sends an RPMAck to the orig- 
inal Resolve Port Mapping message back to the BSCM 
with the address and port of the Terminal (A:b) and the 
address and port of its public IP (R:r). The BSCM knows 

50 that the address and port R:r relates to a given middle- 
box, and hence the middlebox is discovered. 
[0056] In a preferred example, the middlebox control 
node uses middlebox communication (MIDCOM) proto- 
col (as defined by the Internet engineering task force, 

55 IETF MIDCOM working group) in order to control the 
middleboxes. One advantage of the present invention 
is that the middlebox-identity-providing node does not 
need to have the ability to operate a protocol such as 
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other entity (16) connected to a second middlebox 
(11) in the communications network. 

4. A method as claimed in claim 1 wherein the middle- 
5 box-identity-providing node is selected from: one of 

the middleboxes; a gateway in the communications 
network; said one entity, being a user terminal in the 
communications network; a gateway comprising a 
business services channel manager (BSCM). 

10 

5. A method as claimed in claim 3 wherein said call 
passes through two or more middleboxes (10, 11) 
and wherein information about the identity of each 
such middlebox is added to said control message. 

15 

6. A method as claimed in claim 1 wherein said mid- 
dlebox control node is a MIDCOM agent. 

7. A method as claimed in claim 1 wherein said mid- 
20 dlebox control node is distributed and comprises 

more than one node in the communications net- 
work. 

8. A method as claimed in claim 1 wherein each of the 
25 middleboxes is selected from, a firewall, a network 

address translator (NAT), and a quality of service 
device. 

9. A method as claimed in claim 1 wherein said mid- 
30 dlebox-identity-providing node is arranged to deter- 
mine the identity of the first middlebox either by us- 
ing pre-specified information, or by automatically 
analysing the communications network. 

35 10. A communications network comprising: 

(i) a plurality of middleboxes, each connected 
to a plurality of entities in an address realm of 
the communications network; and character- 

40 jsed in that the communications network fur- 

ther comprises: 

(ii) a middlebox-identity-providing node ar- 
ranged to receive a control message compris- 
es jng information about one of the entities and to 

determine the identity of a first middlebox con- 
nected to said one entity; 

(iii) a middlebox control node arranged to re- 
50 ceive the determined identity of the first middle- 
box in order to control said first middlebox; said 
middlebox-identity-providing node being sepa- 
rate from the middlebox control node and being 
more directly connected to said one of the en- 

55 tities than the middlebox control node. 



MIDCOM for controlling the middleboxes. The MIDCOM 
protocol is described in the following Internet Drafts of 
the IETF which are incorporated herein by reference: 

Middlebox Communication Architecture and 
Framework, October 2001 

Middlebox Control (MIDCOM) protocol architecture 
and requirements, July 2001 
MIDCOM Scenarios, May 2001 

[0057] Any range or device value given herein may 
be extended or altered without losing the effect sought, 
as will be apparent to the skilled person for an under- 
standing of the teachings herein. 
[0058] A range of applications are within the scope of 
the invention. These include situations in which it is re- 
quired to control middleboxes and/or to provide middle- 
box identity information to a middlebox control node. 



Claims 

1 . A method of controlling one of a plurality of middle- 
boxes (10, 11) in a communications network, each 
of the middleboxes (10, 11) being connected to a 
plurality of entities (1 4, 1 6) in an address realm (D1 , 
D2) of the communications network, characterised 
in that said method comprises the steps of:- 

(i) receiving a control message at a middlebox- 
identity-providing node (20, 21) in the commu- 
nications network, said control message com- 
prising information about one of the entities 
(14) in the communications network; 

(ii) using the middlebox identity providing node 
(20, 21) to determine the identity of a first mid- 
dlebox (10) connected to said one entity (14); 

(iii) sending said identity to a middlebox control 
node (18) in the communications network in or- 
der to control said first middlebox (10); 

and wherein the middlebox-identity-providing node 
(20, 21) is separate from the middlebox control 
node (18) and is more directly connected to said 
one of the entities (14) than the middlebox control 
node (18). 

2. A method as claimed in claim 1 wherein said step 
(iii) of sending said identity comprises adding said 
identity to a control message and sending said con- 
trol message. 

3. A method as claimed in claim 1 wherein said control 
message is a call set-up message and said method 
is arranged to control said first middlebox (1 0) in or- 
der to set-up a call from said one entity (14) to an- 



11. A signal comprising a session description protocol 
message and characterised in that the session 
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description protocol message comprises an at- 
tribute containing information about the identity of 
a middlebox. 

12. A signal as claimed in claim 11 wherein said infor- 
mation about the identity of a middlebox is selected 
from, a fully-qualified domain name (FQDN) and an 
internet protocol address. 

13. A middlebox control node (18) arranged to control 
a plurality of middleboxes (10, 1 1 ) in a communica- 
tions network, characterised In that said middle- 
box control node comprises: 

(i) an input arranged to receive a control mes- 
sage comprising information about the identity 
of one of the middleboxes (10); 



(10, 11); and to 

issue messages to the identified middlebox in 
order to control it. 

5 

1 6. A computer program stored on a computer readable 
medium and characterised in that it is arranged to 
control a middlebox-identity-providing node (20, 21 ) 
as claimed in claim 14 in order to: 

w 

receive a control message comprising informa- 
tion about one of a plurality of entities (14, 16) 
in the communications network; 

15 - determine the identity of a first middlebox (1 0) 
connected to said one entity (14); and 

send said one entity to a middlebox control 
node (18) in the communications network. 



(ii) a processor arranged to issue messages to 
the identified middlebox in order to control it; 20 
such that in use the middlebox control node 
(18) is able to control the identified middlebox 
(10) without the need to maintain its own store 
of information about the identities of the mid- 
dleboxes (10,11) and without the need to main- 25 
tain its own discovery mechanism to discover 
the identities of the middleboxes. 



14. A middlebox-identity-providing node (20, 21) for 
use in a communications network comprising a plu- 30 
rality of middleboxes (10, 11), characterised in 
that said middlebox identity providing node com- 
prises: 

(i) an input arranged to receive a control mes- 35 
sage comprising information about one of a plu- 
rality of entities (14, 1 6) in the communications 
network; 

(ii) a processor arranged to determine the iden- 40 
tity of a first middlebox (10) connected to said 
one entity (14); 

(iii) an output arranged to send said identity to 

a middlebox control node (1 8) in the communi- 45 
cations network; and wherein said middlebox- 
identity-providing node (20, 21) is arranged to 
be more directly connected to said one of the 
entities (14) than the middlebox control node 
(21,21). so 

1 5. A computer program stored on a computer readable 
medium and characterised in that it is arranged to 
control a middlebox control node (1 8) as claimed in 
claim 13 in order to 55 



receive a control message comprising informa- 
tion about the identity of one of the middleboxes 
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